The following is a list of how the existing sensor library needs to be changed to suport the new vendor setups. as well as the ways that TELs and Teemss wants to use this library.

• sensor query: there should be a sensor query language. So an author can specify what kind of sensor they need for an activity. The parts of this spec would be quantity measured (temp, pressure, distance), external sensing (internal versus external sensors), response time (speed of temp sensor), collection speed (samples per second)
• auto id: support for sensors and sensor interfaces that id them selves. Currently a user of the library specifies which sensor they want, and then it expects that sensor to be plugged in. In an auto id situation the sensor should be validated against what the author wants, and then an error reported if it is incorrect.
• fluctuationg time sequence: some vendors do not push data to the computer. Instead the computer must poll the interface for the data. This will be very difficult in waba since there are no threads. So perhaps the best is to allow for chaning time increments.

There are two current uses for this library. The first is in the TELS project the second is in the Teemss project. In both of these projects it would be ideal if users of library would not need to specify the model of a sensor and sensor interface. Instead they should be able to specify the ranges and type of sensor they want. The binding of this abstract spec to a real probe might happen at different times.

For example, in teemss the curriculum author will specify a probe in their activity. Then a school will log into the teemss portal and download this activity. We would have information at this point about the schools set of sensors. So the abstract probe specification could be converted to a real probe on our server before the activity is downloaded.

In this mode it would be nice to show the schools which activities they can and cannot do based on what probes they have.

In the TELS project the same thing could happen. But also these activities are used as demos sometimes so it would be nice if the activity would be able to figure out the best probe at run time. For example the activity would get to the point where a probe is needed and pop up a dialog that says please insert a temperature probe. The user goes and find their GoTemp probe plugs it in and the dialog box goes away. Or the user plugs in their Fourier eco-log and then has to pick that from a list of supported devices.